iT邦幫忙

ai engineering相關文章
共有 48 則文章
鐵人賽 AI Engineering DAY 8

技術 [Day 22]:Guardrails 可以防止幻覺嗎?從企業 RAG 的 Groundedness 談起

Guardrails 可以在回覆交付前,攔下部分缺乏來源支持的內容。但要說它「防止幻覺」,還得先問:這次檢查依據哪份資料,檢查了回答裡哪些主張? 前一篇談的是客...

鐵人賽 AI Engineering DAY 8

技術 [Day 19]:一份萬字文件裡只有一句個資:長文本 PII Guardrails 怎麼做?

新的章節:到底企業需要哪幾大類的 AI Guardrails? 在實際的企業場景裡,我們常常會遇到到底要使用哪些 AI 護欄的問題;大部分人想到的可能都是如何使...

鐵人賽 AI Engineering DAY 8

技術 [Day 17]:客服案例實戰:從 Rule、Reward、Judge 到 Human Review 的完整評估流程

一段客服逐字稿要交給摘要模型,但模型不能取得原始個資。姓名、電話和地址得遮住,顧客要查詢配送進度這件事又必須留下。做完去識別化後,怎麼確認這份資料能用? 今天沿...

鐵人賽 AI Engineering DAY 8

技術 [Day 16]:Human-in-the-Loop 不等於所有資料都給專家看

Day 14 裡,筆者遇過候選已經提供正式求助窗口,Judge 卻說它沒有提供的情況。Day 15 則談到另一個限制:Reward Model 能替同一組候選排...

鐵人賽 AI Engineering DAY 8

技術 [Day 15]:Reward Model 比 LLM 便宜,那能直接用它換掉 LLM As A Judge 嗎?

前兩篇已經花了不少篇幅談 LLM-as-a-Judge:Day 13 說明它適合判斷哪些問題,Day 14 則處理 Judge 自己也可能誤判的情況。到了 Da...

鐵人賽 AI Engineering DAY 8

技術 [Day 14]:Judge 也會亂判:筆者踩過的 LLM-as-a-Judge 大大小小坑

上一篇 Day 13 談 LLM-as-a-Judge (下稱 Judge)適合處理什麼時,筆者把它的位置放得很清楚:由規則式(Rule)Guardrails...

鐵人賽 AI Engineering DAY 8

技術 [Day 13]:LLM-as-a-Judge 到底適合判什麼?

在 Day 12 文章裡談規則式(Rule)Guardrails 時有個界線很明顯:有些事情只要條件寫得夠清楚,根本不需要 LLM As A Judge 來協助...

鐵人賽 AI Engineering DAY 8

技術 [Day 12]:能用規則 (Rule) 判斷的事情,就不要先叫 LLM

在 Day 10 的文章裡,筆者把合成資料的品質檢查拆成三層:先看資料結構,再用確定性規則核對已知條件,最後才把難以直接寫成規則的問題交給語意判斷。 讀者可能會...

鐵人賽 AI Engineering DAY 8

技術 [Day 11]:實戰-組合 Day 7-Day 10 的心法、以 PII Guardrails 為目標合成測試資料

Day 7 到 Day 10 分別談了 Seed、Stage、Dependency 與 Quality Control。四個部分各自拆清楚後,要把它們接成一條...

鐵人賽 AI Engineering DAY 8

技術 [Day 10]:資料生得出來不代表能驗收:替合成管線設計 Quality Control 機制

Day 9 把 redacted_text 和 entity_candidates 接回同一版 source_text。這能避免三份資料各說各話,卻還不能回答一...

鐵人賽 AI Engineering DAY 30

技術 Day 30|從 Vibe Coding 到 Agent-ready 的開發方法

耗時4個月,權限管理平台正式上線,超過 100 位使用者開始使用。 在這過程中,驗證 13 項功能的結果輸出,再用兩輪 UAT、合計 13 個情境檢查跨角色流程...

鐵人賽 AI Engineering DAY 8

技術 [Day 8]:不要叫模型一次生成:合成 PII 測試資料時拆成可追蹤的階段任務(Stage)

昨天 Day 7 的文章先把一筆 Guardrails 測試案例寫成種子資料(Seed Contract),分清楚哪些條件要固定、哪些內容可以變化,以及哪些資訊...

鐵人賽 AI Engineering DAY 7

技術 [Day 7]:先別寫 Prompt:先設計出資料種子(Data Seeding)來定義案例、邊界與資料分布

上一篇先把 Guardrails 的六個驗收情境改寫成合成資料需求,並且分清楚三類條件:哪些一定要固定、哪些可以變化、哪些不能交給模型自行發明。 接下來很容易直...

鐵人賽 AI Engineering DAY 6

技術 [Day 6]:客戶資料不能拿出來,我們要怎麼測 AI Guardrails?

在 Day 5 的文章中我們把「不要洩漏個資」拆成六個可以重跑的驗收情境,而文章最後留了一個很實際的問題:在測試 Guardrails 時三個案例可以手搓一搓生...

鐵人賽 AI Engineering DAY 5

技術 [Day 5]:Guardrail 有擋到就算驗收?把企業政策 (Policy) 變成可以一直重跑的測試、實踐 Policy As Code

筆者在 Day 4的文章裡談到,企業為什麼不能只要求 Guardrail「接得上」或「能跑得動就好」。 當企業今天用了 A Guardrail,半年後可能換成...

鐵人賽 AI Engineering DAY 25

技術 Day 25|超過 100 份 Spec 怎麼整理:建立 Agent 讀得懂的文件地圖

持續三個月的努力,DAP 在7/31正式開放上線了。 系統上線後,需求還是持續進來。回頭整理這三個月的開發紀錄,specs/ 已經累積 107 個編號資料夾,我...

鐵人賽 AI Engineering DAY 4

技術 [Day 4]:手搓 Guardrail 不難,企業真正難題怎麼把它管起來

筆者在 Day 3 的文章中把「不要洩漏個資」這句要求,拆成三件事: 系統要檢查什麼 照什麼規則判斷 發現問題後要怎麼處理 如果今天只有一個客服系統、一個模...

鐵人賽 AI Engineering DAY 24

技術 Day 24|兩輪 UAT 怎麼收口:快速修正,也要決定哪些先不上線

兩輪 UAT 合計準備 13 個功能情境。第一輪檢查跨角色流程,第二輪讓申請人操作。 這一階段的開發工作都交給指揮中心管理。它負責分流、檢查檔案衝突與安排 A...

鐵人賽 AI Engineering DAY 2

技術 【Day 2】名詞定義(上):六個基礎名詞

Agent、Harness、Tool、MCP 這幾個詞在不同框架的文件裡指涉的範圍各有出入,同一個詞在甲專案是協定規範,在乙專案是產品名稱。以下先把六個基礎名詞...

鐵人賽 AI Engineering DAY 3

技術 [ Day3]:「不要洩漏個資」太模糊:怎麼把政策轉譯成 Guardrails 可以測試的控制項?

Day 2 把 Guardrails 可以介入的位置展開了:從使用者輸入、檢索資料,到工具執行前後,都可能需要控制。但架構圖、流程圖畫完,工程師還有一個問題沒得...

鐵人賽 AI Engineering DAY 1

技術 【Day 1】前言:從「能動」到「能一直動」

去年我做的是處理會議紀錄的 Agent,今年做的是常駐 Agent,這兩件事的難點落在不同的地方。 會議 Agent 的問題是一次性的:語音轉文字、摘要、寄信,...

鐵人賽 AI Engineering DAY 23

技術 Day 23|規劃五個工作天:用優先矩陣安排第一波 UAT 修正

第一輪 UAT 結束後,規則確認、修正、重驗和第二輪測試資料準備,全部要放進這五個工作天。 Day 22 收到的回饋有大有小:單據無法結案會直接卡住流程,專案沒...

鐵人賽 AI Engineering DAY 22

技術 Day 22|第一次 UAT:用跨角色走查找出流程斷點

第一輪 UAT 開始,什麼請況都會出現,使用者如何操作真的是很難預期。 第一批人開始操作後,有一張單據從申請、審核一路走到最後,按下結案時卻出現伺服器錯誤。 原...

鐵人賽 AI Engineering DAY 1

技術 [ Day 1]:AI Guardrails 不應只是 AI Security、更是企業實踐 GRC 的手段之一

談到 AI Guardrails,常見的反應是:「這是 AI Security 的事吧?」也有人會問:「把限制寫進 Prompt 不就好了?」或是:「模型都這麼...

鐵人賽 AI Engineering DAY 21

技術 Day 21|UAT 我的規劃架構與修復原則

距離第一次 UAT 前,剩下四天 6 月 27 日,指揮中心第一次完成一整批需求,還剩下一些小功能調整後,7 月 1 日,系統就要交給第一批 UAT 人員使用,...

鐵人賽 AI Engineering DAY 20

技術 Day 20|UAT 前,我先把 13 項功能的 JSON 全部重跑一次

Part 4|倒數 31 天:從「AI 做完了」到「使用者真的能用」(Day 20–30) 指揮中心流程完成後,我陸續將要修改的部分都使用這個流程處理,所有功能...

鐵人賽 AI Engineering DAY 1

技術 Day 01:五年後再談 AI 落地 — 為什麼是「雙主軸」?

2021 年,我在鐵人賽寫了《從 AI 落地談 MLOps》(GitHub)。那 30 天在回答一個問題:模型訓練好了,然後呢? 五年後,這個問題不但沒有過期,...

鐵人賽 AI Engineering DAY 19

技術 Day 19|我以為 Agent 越多越快

Day 14 到 Day 18 鋪的東西——角色、Skill、分流、排批次——這一篇第一次合體。六月底一個早上,我的清單上有 30 多項任務。距離 7 月 3...

鐵人賽 AI Engineering DAY 18

技術 Day 18|多個 agent 同時動工前,先排好誰先誰後

為了不讓兩個 agent 同時改同一個檔案,導致後做的會把先做的蓋掉。 所以六月底那天走完整流程的 3 個任務,指揮中心沒有一次全部丟出去。那時距 7/31 上...

鐵人賽 AI Engineering DAY 17

技術 Day 17|一批需求進來,先分流:小改直接做,新功能才走完整流程

Day 14 那天的 11 個任務,是我手動分類的:哪些是 bug、新功能、文字調整。後來這件任務寫進了指揮中心 /orchestrate,變成它收到任務檔之後...